Service Discovery : Access to Local Resources in a Nomadic Environment

We propose a standard level of support for nomadic computing in which a mobile client can move into unfamiliar environments and obtain services for which it has no corresponding client RPC stub. We call this activity service discovery and motivate its importance for mobile computing. This paper describes the general components of service discovery and points out where traditional paradigms of distributed computing fall short of its requirements. We suggest an architecture for an environment which uses a directory service based on the ODP trading function and a dynamic interface mechanism for ad hoc client-server interaction. 1 INTRODUCTION The goal of nomadic computing transcends simply making one's environment portable; mobile users require the ability to communicate with local servers despite location and the ability to obtain local services despite statically defined service interfaces. To this end, we expect the portable computer or PDA to perform as a " universal inter-actor " [46]. There are three fundamental problems that need to be addressed to achieve a minimal level of interaction: 1. How does a mobile client locate an appropriate resource? 2. How does a mobile client interact with the (server providing access to the) resource? 3. What physical communication is used? The first problem is largely solved. The second is not. The third has a simple short-term solution. Location. A client can locate resources via a directory. There are several such directories, including the CCITT X.500 Directory [7], CORBA's Interface Repository [31], and the ODP trading function [22]. There are also several academic systems including Prospero [30] and Cygnus [8, 9, 39]. These systems provide methods that enable clients to locate services in a distributed environment. We have previously described the flexibility of the trading function in [23]. Whatever one's choice of directory, the point remains: the ability exists for a client to locate services based solely on descriptions of the service desired, rather than some specific piece of knowledge such as the name of the server or a unique ID referencing the service. One could even go as far as using the Web [3] to locate services, as many cataloging and webpage-directory services already exist. Interaction. A client must be able to communicate intelligently with servers that it has never heard of before. This implies not only that the client does not have an RPC stub for the appropriate service interface, but that the client does not need an RPC …